Next.js 프로젝트에서 JWT 쿠키/토큰 관리 관련해 조언을 부탁드립니다!

Q. Next.js 프로젝트에서 JWT 쿠키/토큰 관리 관련해 조언을 부탁드립니다!

포포테토칩00

Next.js(App Router)에서 JWT 액세스·리프레시 토큰을 HttpOnly 쿠키로 관리 중입니다. 클라이언트는 axios, SSR·Route Handler는 fetch로 요청하다 보니 401 처리와 재발급 흐름이 분리됩니다. 특히 SSR에서 토큰이 필요한 데이터를 가져올 때 401이 발생하면 SSR은 새 토큰을 브라우저에 반영할 수 없어 계속 실패하는 문제가 있습니다. 그래서 실무에서는 이 상황을 어떻게 해결하는지 궁금합니다. ❓ 질문 1 SSR에서 토큰 기반 데이터를 패칭하다 401이 발생하면 실무에서는 보통 어떻게 처리하나요? SSR은 쿠키 갱신이 불가한데, 이런 경우 어떤 흐름으로 정상 상태를 복원하는지 알고 싶습니다. ❓ 질문 2 SSR과 클라이언트 요청에서 토큰을 함께 쓰는 환경에서 401 처리·재발급·에러 흐름 같은 공통 로직은 보통 어디에 두나요? Route Handler를 단일 통로로 두는 구조가 일반적인지도 궁금합니다.

2025.11.25

답변 1

프로답변러YTN
코부사장 ∙ 채택률 88%
채택된 답변
멘티님 상황에선 SSR이 401을 만나면 그 자리에서 재발급·쿠키 세팅을 시도하지 말고, 바로 “쿠키를 쓸 수 있는 레이어(예: /api/auth/refresh, server action, middleware)”로 리다이렉트시키고 그 레이어에서만 refresh 토큰으로 재발급 + Set-Cookie 후 원래 페이지로 돌려보내는 흐름을 쓰는 게 가장 현실적인 패턴입니다. SSR에서 fetch로 백엔드를 직접 치지 말고, SSR·클라이언트 모두 Next.js Route Handler(또는 BFF)만 호출하게 한 뒤 이 통로 안에서만 쿠키의 access/refresh 토큰을 읽고, 401이면 백엔드 refresh 엔드포인트 호출 → 성공 시 새 토큰을 쿠키에 세팅하고 원래 요청을 재실행 → 실패 시 로그인 페이지로 리다이렉트하는 식으로 “정상 상태 복원”을 통합하는 것이 많이 쓰입니다. 공통 로직은 보통 두 층으로 나누는데, 서버 공통 로직은 server-only fetch 래퍼나 /api/* Route Handler 안에 두고 거기서만 Authorization 헤더 주입·401 재시도·Set-Cookie를 담당하게 하고, 클라이언트는 axios 인스턴스 하나에 response 인터셉터를 걸어 401 시 /api/auth/refresh를 호출한 뒤 성공하면 원래 요청을 다시 보내도록 해서 “토큰 처리 코드가 퍼지지 않게” 모읍니다. 실무 예제들을 보면 App Router 환경에선 “모든 인증이 필요한 데이터 요청은 반드시 Next.js 서버를 거쳐 외부 백엔드로 나가게 하는 BFF 구조 + 필요하면 middleware로 사전 토큰 검증·리다이렉트” 조합이 가장 흔하고, 이 구조를 쓰면 멘티님이 겪는 ‘SSR은 쿠키를 못 고쳐서 무한 401’ 문제도 자연스럽게 해소됩니다. 채택부탁드리며 파이팅입니다!
*현직자 3만 명의 취업 정보가 실시간 업데이트됩니다.
2025.11.26
AD
반도체
설계팀
대기업 반도체 산업으로 취업하기 위해선, 직관적 해석능력과 사고력이 필요합니다. 핵심 역량과 배운 지식을 취업에 활용하고 싶다면 국비지원 강의를 추천합니다.